fix(routing): use default api_base for firmware provider#99
fix(routing): use default api_base for firmware provider#99b3nw wants to merge 2 commits intoMirrowel:devfrom
Conversation
Users with FIRMWARE_API_KEY_* but no FIRMWARE_API_BASE were getting errors because LiteLLM doesn't recognize firmware as a native provider. This adds a specific fallback to use firmware's default api_base (https://app.firmware.ai/api/v1) when not explicitly configured.
|
I'm starting my review of the tactical fix for the Firmware.ai provider. I'll verify the default API base detection and ensure it correctly routes through the OpenAI-compatible flow. 🛡️ |
![mirrobot-agent[bot]](https://avatars.githubusercontent.com/in/2140342?s=60&v=4){kind=small}
There was a problem hiding this comment.
Overall Assessment
This PR provides a solid tactical fix for Firmware.ai users. By providing a default api_base and marking it as a custom provider, the rotator can correctly route requests for firmware/* models even when FIRMWARE_API_BASE is not explicitly set in the environment. This ensures a smoother out-of-the-box experience for users with Firmware API keys.
Architectural Feedback
None. The approach is consistent with how other custom providers are handled, and the implementation correctly leverages the existing convert_for_litellm routing logic.
Key Suggestions
None. The implementation is clean and follows existing project patterns.
Nitpicks and Minor Points
- The hardcoded URL
https://app.firmware.ai/api/v1is correct for Firmware.ai's current API. - The use of
KNOWN_PROVIDERScheck ensures that if LiteLLM eventually adds native support, this fallback won't interfere with their implementation (provided they use the same name).
Questions for the Author
None.
This review was generated by an AI assistant.
Firmware.ai uses custom model naming (e.g., firmware/anthropic/claude-sonnet-4-5) that isn't in LiteLLM's pricing database, causing "Provider List" spam and BadRequestError during cost calculation. Add skip_cost_calculation=True to FirmwareProvider to prevent these errors. The provider is OpenAI-compatible and routes through LiteLLM's OpenAI provider with api_base override, so no custom acompletion() logic is needed.
1 participant
Summary
Tactical fix for users with
FIRMWARE_API_KEY_*env vars but noFIRMWARE_API_BASEset.Problem: LiteLLM doesn't recognize "firmware" as a native provider, so requests for
firmware/*models were failing whenFIRMWARE_API_BASEwasn't explicitly configured.Solution: Add firmware-specific fallback in
_load_api_bases()to use the default API base (https://app.firmware.ai/api/v1) when not explicitly configured.Changes
src/rotator_library/provider_config.py: +10 lines adding firmware default api_base detectionTesting
firmware/*models to OpenAI-compatible with correct api_baseImportant
Adds default API base for 'firmware' in
provider_config.pyto ensure requests succeed without explicit configuration._load_api_bases()inprovider_config.py.FIRMWARE_API_BASE.This description was created by
for d9148bb. You can customize this summary. It will automatically update as commits are pushed.